When under a particularly strict programming deadline (like an hour), if I panic at all, my tendency is to jump into coding without a real plan and hope I figure it out as I go along. Given enough time, this can work, but in an interview it's been pretty unsuccessful, if not downright counter-productive. I'm not always comfortable sitting there thinking while the clock ticks away.

Is there a checklist or are there techniques to recognize when you understand the problem well enough to start coding? Maybe don't touch the keyboard for the first 5-10 minutes of the problem? At what point do you give up and code a brute-force solution with the hope of reasoning out a better solution later? When is it most productive to think and design more vs. code some experiments to and figure out the design later?

Here is a list of techniques for taking a math test and another for taking an oral exam. Is there is a similar list of techniques for handling a programming problem under pressure?

ANSWERS: I think this is a valid answer: How To Solve It. I found the link as an answer to Steps to solve or approach towards a solution. There were also some really good tips at Is thinking out loud during an interview really the best strategy?. A great and concise argument for TDD is the first answer to TDD Writing code vs Figuring out the answer to a problem?. My question may be a near-duplicate of that one.